Up Against The Wall! By Anthony Bailey

An Editorial by Anthony Bailey (QdQ)

1. Clearly, it ought to have been mentioned that walls are dangerous in DeathMatch because of the danger of taking splash damage from rockets exploding against them. So don't wall-hug whilst running from an enemy! Wall-hugging to catch up with them has great potential though, since you can punish them if they try the same trick.
2. You can floor-hug and ceiling-hug too, if you are underwater. Just +moveup or +movedown against the obstruction instead of +moveleft or +moveright against the wall. This speeds up swimming a little bit (though not inordinately.) No, before you ask, it doesn't work out of water...
3. Credited Doudou as originator of the 180^o degree turn alias.
4. Thomas Habets writes with another interesting observation:

   Just wanted to say that you don't actually need to press forward to wall-hug, I measured 469 pixels per second with just +moveright at angle -50.6 or -52 (not sure, I think -50.6) where the wall goes -90. Good if you want to do a drive-by.

About a month ago I wrote an article here on PlanetQuake entitled ZigZagging Through A Strange Universe. Within it, I had a look at some of the weird physics anomalies in DooM and in Quake, and I described one new trick in particular, "zigzagging", that lets you run a bit faster than normal. If you haven't already taken a look at the article, I'd suggest you do so now, to set the scene for this follow-up.

ZigZagging Through A Strange Universe generated quite a lot of interesting e-mail, as people wrote me about other odd bits and pieces of Quake they'd noticed, and also related a few zigzagging experiences. Most importantly, an entirely new trick for running fast came to light as a result of several people independently playing with the QdQvel Quake-C modification for measuring running speed.

Whereas zigzagging can increase speed by around 20%, but will murder your fingers and keyboard, this new technique can give at least double that speed-up, and is no more difficult to do than DooM's strafe-running was. Now, zigzagging can be useful, especially if you learn to use it effectively. But all but the most serious Quakers may well find it is more trouble than it is worth. However, wall-hugging is a different matter. If you play multiplayer and speed is ever an issue for you, you'll want to know about this one.

Feedback

But all that in good time. I'll start by looking at some of the issues that were raised in response to the previous article.

Some people wrote to suggest answers to one or two questions I asked about the history of rocket-jumping, as well as noting that in some ways the idea actually dates back as far as DooM!

Talking of things that date back to DooM, a few people rediscovered the mathematics behind strafe-running and wrote to tell me all about it. Thanks, folks, but of course it doesn't work in Quake...

Well, in fact, that's not altogether true: whilst it won't do you any good in regular Quake, where you already run fast enough in a straight line that taking a diagonal path would take you over the sv_maxspeed limit, it can be useful in some Quake variants. An example of this is found in TeamFortress, where some of the characters have much slower speeds than others, and hence sv_maxspeed is higher than their running speeds. Soldiers, for example, should find diagonal running to be effective. Thanks to God Virus for that one.

With regard to the comment about speed in water that I made in the previous article: although players with faster machines will find they can swim faster in single-player games, in network play, only the speed of the server is important and so all players on the same server will have the same capabilities. This situation will come up again when considering wall-hugging, and is a result of some facts about client and server framerates. There is one additional strange fact about water (thanks, Rob Butler): you don't need your head above the surface in order to breathe. You're fine as long as any part of your body is in the air (e.g. your feet.)

The air that Quake-guy breathes is also the air that you jump through; and that's pretty strange too, really.

Zigzagging is hard to do by hand. It's very tiring, and it takes practice to get right. As a result, it would be nice to do it automatically. In the previous article, I suggested that aliases for doing it were rather tricky. There are two main reasons for that. Firstly, the effectiveness of the alias will be reliant on both the client and server framerate - this varies from situation to situation and from server to server. Secondly, whilst the alias is running you can't send other commands - which means sacrificing some of your, er, self-control. 

Still, both these problems can be combatted, even if they can't be solved completely.

Steady as she goes

To make the client framerate a little more reliable you can momentarily freeze it by setting host_framerate for a short period. You can't do this for long, because the client and server will drift out of sync and cause a disconnect. But for short bursts, it doesn't seem to cause problems.

For example, here's something one often sees requested by keyboarders: a totally reliable alias to perform a one hundred and eighty degree turn. It will work in single-player or in network play, and was originally written by Doudou.

alias turn180 "host_framerate 0.03; wait; cl_yawspeed 8000; +left; wait; -left; cl_yawspeed 140; host_framerate 0";

1. Changing host_framerate is definitely cheating in the realms of single-player Quake. It's also perhaps pushing the edges of the acceptable in Net play to do it on the client.
2. The value used for cl_yawspeed presumes you are using the "run" key (i.e. +speed is on) and that cl_anglespeedkey is set to its default of 1.5. Without using +speed, the figure you require is 12000 rather than 8000 (which is equal to 12000 / cl_anglespeedkey).
3. You should be playing with the mouse anyway, llama!  [trad.]

The same idea can be applied to zigzagging. The details can get complex, and really everybody should fine-tune their own aliases to fit their playing style and normal display framerate. But as long as you are changing direction at a fairly regular rate of about twenty times a second, that's the main thing. You can inspect my own little zigzag alias file to get an idea of how you might work things. I owe a million thanks to Matthias Buecher for all his experimenting and investigating into how practical this was - here's his own short, sweet, and pretty effective alias for zigzagging:

alias zigzag "+moveleft;wait;wait;-moveleft;+moveright;wait;wait;-moveright";
bind h "host_framerate 0.01;zigzag;zigzag;host_framerate 0";

I'm out of control!

If you don't mind sacrificing control of the yourself for a longer period of time, you could write an alias that zigzagged maybe fifty or a hundred times without you having to do anything. Trouble is, you won't be able to do anything else much, either.  You will be able to steer with the mouse (though not with the keyboard - but of course, you already use the mouse for this, don't you?) but you won't be able to stop going forward, or switch weapons, or jump, or start firing.

But sometimes, this doesn't matter. If all you really care about is getting the hell out of there because some fragger behind you is about to finish you off, that would be an ideal time to risk letting the machine zigzag you out of there.

The other thing is that although you can't start or stop firing, you can carry on doing it. So if you send an +attack command by pressing fire and then start the long zigzag alias before sending -attack by letting go of the fire button, you'll carry on shooting all the time that you zigzag. This variant is useful when in hot pursuit. Thanks to Triton for this idea.

Finally on the zigzag front, John Cox wrote to me with a story about a broken Logitech Trackman Marble trackball that did something rather like zigzagging all the time because some of its sensors had broken off. It was apparently very useful for racing up and down corridors, but I'm not sure he advised wrecking your trackball for use in regular deathmatch. 

Hugging the wall

That's enough looking at ways to make old and flawed tricks more useful. Here's the new trick. To understand the way in which it works, or to get the very last drop of utility out of it, you'll have to understand quite a lot of technical stuff; the ins and outs of the server framerate, the difference between +speed and the "Always Run" option, a complicated relationship between various angles, framerates and client-side variables. (You might also want to consider how far you can play around client-side before it becomes cheating.)

But although the explanation and the exact details of the trick are painfully complex, the basic technique is ridiculously simple, and you can go off and do it straight away:

Whilst running along a corridor, strafe into one of the walls at the same time.
You'll probably want to use dedicated keys for strafing left and right, since fine-tuning the angle you are at relative to the wall helps maximise your speed.

Credit where credit is due: the person who discovered this technique the first, as far as I am aware, is Matt McChesney. He also built a little testing map for checking things out in which I found very useful. Thanks, Matt. Walter Elly and Chris Elly also wrote to us with news of it too. I'd like to thank all three people, not least for being so kind as to write to QdQ and thus give us a chance to research it properly before publishing this article.

The first question to ask is: if it's something so simple, and it makes you go quite a bit faster, wtf didn't anyone notice before they had the speedometer to play with? One might assume that some people have known about this for a while and wanted to keep it for themselves. Hey, if every fragger has been beating you recently, maybe you've found your excuse, right? They knew about this all along! Well, as the Weenie Guide would say, maybe - but it's much more likely that you suck.  Ah well, maybe you'll have the edge again until they read this article. 

I messed around a little with the previous QdQvel patch to make it more useful for tracking how you're doing when practising all these techniques. The new version will track such things such as average and maximum velocities so it should be easier to read and use.

Squeezing performance

Now, on average, most people find they get a speed of more than 400p/s using this method. Normally, significantly more: anything up to a 40% speed increase, which is about the same as the speed-up provided by strafe-running in DooM. But depending on the circumstances, you can optimise this further - in the most extreme conditions, I've recorded speeds almost as high as 500p/s, which is really pretty speedy.

I'll now go through the factors that have an affect on the best speeds you can reach.

Server framerate

The greater the frequency with which the physics of the game are calculated (i.e. the faster the machine running the Quake server), the faster will be the maximum speed you can get to.

Note that this does not mean that those playing on a better machine will have an advantage in multiplayer. Well, not any more than normal, anyway; the smoother display and the extra precision allowed by a higher client framerate are already very useful for players on fast machines. But the actual physics of the game, and hence the abilities of the players, will be equal across the server you are playing on. This is a good thing, as one wouldn't want multiplayer Quake to become any more inequitable than variable ping-times already make it.

It does mean that in order to get the most out of wall-hugging, it helps to know the server framerate. To the best of my knowledge, there isn't a general way in which to do this from the client end.

It also does mean that in single-player competitions, a faster machine will give you an advantage (since in this situation, you run the server yourself, and so different people effectively have different servers.) This is a shame, but that's the way it is, alas.

Angle to the wall

You don't need to run exactly parallel to the wall to make this trick work; you can run at quite an angle in to it or even out from it, and the strafing motion will still keep you tight against the wall rather than allowing you to lose contact with your friendly accelerator.  Some angles in Quake are stored only as one of 256 different directions around the 360 degree circle, meaning they are quantised in 1.4 degree increments - this happens to be one such angle, so you don't have to be as precise as you might fear to get best results. Even so, a degree or so isn't a great margin for error, and going the wrong side of the optimal angle will have a noticeable affect on the speed you get up to. Different angles are optimal for different framerates and for different values of the final variable, which is described below.

Ratio of cl_forwardspeed to cl_sidespeed

Heh, that one looks a little scary, doesn't it? I told you this got a little bit complicated. 

These two variables determine the speed your client would like to run at in the two directions you'd expect. Of course, the server is keeping a watchful eye on the maximum speed you can reach, so you'll have no joy if you just increase these and expect to go faster and faster. However, the ratio between them determines the angle you'll go at if you strafe and go forward and the same time - and this will have an effect on the speed-up you get from wall-hugging.

The default value for cl_sidespeed is 350p/s, and there's really no reason why you should ever have changed it, or should ever want to change it. Thus in the following, I'll assume that's the value it has, and so concentrate only on changes to cl_forwardspeed.

The first thing to note is that using the "Always Run" menu option simply sets cl_forwardspeed to 400 to get a rough and ready approximation of using the "run" command, +speed. You don't want to use it anyway, it has has a number of disadvantages in any case, but in particular it will interfere with any changes you make to cl_forwardspeed. Switch the option off and forget about it.

The second thing to note is that pressing the run key will make no difference to the total speed you get by wall-hugging. Weird, huh? Presumably this is because it simply doubles the speed you are trying for, and doesn't change the angle you are trying to move in, which seems to be the important thing here.

How these variables work together

Right, having got all that straight, I can proceed to the explanation of how all these factors inter-relate...

So, the maximum speed you can reach is dependent on server framerate. I'll continue by presuming we've fixed this framerate at some particular value; the other values involved will vary smoothly as it changes. Server framerate can vary over time, although in multiplayer games with a dedicated server it doesn't tend to vary very much, so you can get pretty good results despite the variation, at least in principle.

You can reach the maximum speed as long as you have the right cl_forwardspeed to match the angle you are at to the wall. This means that if you don't want to worry about guessing angles, and just want to always run parallel to the wall, there will be some setting of cl_forwardspeed that will optimise results for you at any given framerate. It also means that if you have moral scruples about playing with the values of your client-side variables, you can leave them at their defaults and just try to turn at the correct angle instead. (This is harder, though, and you don't have the same "degree" of accuracy.)

I compiled the important values into a table of results which I didn't want to clutter up this article with. Someone with nice imaging software could probably draw a very pretty four-dimensional graph of the results, but it isn't going to be me. 

Conclusion

To sum up - if you're in a hurry within the universe of Quake, lean into a wall. If you're going to be in a particular hurry in certain environments or on certain routes, you could practise in those conditions and see how fast you can manage (for example, practising running between the bases in CTF and knowing where to zigzag and where to wall-hug sounds like a good plan.) If you want to get technical, start playing with different settings for cl_forwardspeed or different running angles to get the best results under a variety of conditions.

And make the most of it - because both these feature-bugs are gone from Quake2.

Happy hugging...

- Anthony

Comments on this Editorial? Send it to Feedback.

Back to PlanetQuake